home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000824-20010305
/
000153_news@columbia.edu _Thu Dec 28 17:12:34 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2001-03-05
|
3KB
Return-Path: <news@columbia.edu>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
by monire.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA11865
for <kermit.misc@cpunix.cc.columbia.edu>; Thu, 28 Dec 2000 17:12:34 -0500 (EST)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA13264
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 28 Dec 2000 17:12:33 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id RAA02272
for kermit.misc@watsun.cc.columbia.edu; Thu, 28 Dec 2000 17:12:47 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@columbia.edu (Frank da Cruz)
Subject: Re: A wish for the FTP-client
Date: 28 Dec 2000 22:12:46 GMT
Organization: Columbia University
Message-ID: <92gdsu$26u$1@newsmaster.cc.columbia.edu>
To: kermit.misc@columbia.edu
In article <5VP2SCqS3328@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
: In article <92g92f$s9j$1@newsmaster.cc.columbia.edu>,
: fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
: > "...
: > mktime() normalizes the supplied tm structure" -- applies timezone
: > conversions, etc. The problem there is, of course, we don't know, and
: > have no way to find out, the server's timezone, and even if we knew it,
: > what the rules are to convert to our own. The struct tm is *already* in
: > GMT/UTC, and should not be converted to it again.
: >
: > Thus the resulting file date won't be what you want. I think the object
: > of copying the server's MDTM is so update can work in both directions. If
: > we use mktime(), I think the result will have up to 24 hours of randomness
: > added or subtracted. Am I missing something?
:
: I face this problem daily, at 0300 during mirroring operations. As
: Frank notes well, TZ material makes a mess of trying to reproduce UTC stamps
: from FTP information. What I do, and what works reasonably well, is use what
: FTP itself reports in a LIST command (parse according to remote server
: syntax) which is what it thinks the local time/date of the file is. I then
: make the client side report the same time/date at user level. This makes
: local and remote systems "appear" to yield identical file listings.
:
Given the ability to parse an "ls -l" listing, this approach works great when
(a) client and server are in the same timezone, or (b) the client knows what
timezone the server is in and knows how to "pre-unadjust". But in the
general case, the client has no clue as to the server's timezone or daylight
savings rules, and therefore hasn't a prayer of compensating for mktime()'s
adjustments. Also, parsing LIST responses is not a general solution since
the server might not be UNIX, or might be running some kind of "improved"
ls, or whatever.
In truth, FTP protocol and UNIX APIs leave a lot to be desired, especially
when the holes coincide.
- Frank